The Character GUI Twinsen It was 11 months ago when we first mentioned the new Character GUI, in FFF-289. After all that time, it's finally getting ready. Since you can expect to see it released sometime in the next 1 or 2 weeks, we would like to present a quick recap of the features and changes, and some real in-game screenshots. The Character window is now split into 3 tabs. Logisitcs and auto-trash were moved from the central frame into a tab and a new tab called Character was added. Using inventory/stack transfers in the player inventory will transfer the items either to weapons and armor slots or to trash slots depending on the selected tab, regardless of item type. Logistics and auto trash are now merged into 1 panel. Using a double slider you can set an interval. If you have less than the first value, robots will bring more, if you have more than the second value, extra items will be auto-trashed and taken away by the robots. The double pop-up and extra confirm might seem strange, but it's made this way to solve the problem of robots bringing you items before you finished setting up your request. With the merging of requests and auto-trash, we also made it so you can now set an unlimited number of requests, regardless of research. Furthermore, everything is unlocked in one research: unlimited logistic requests, auto trash, and 30 trash slots are all unlocked by the "Logistic robotics" research that is at blue science. Searching now not only searches the recipe GUI, but also the inventory and logistic requests. By popular demand, we also added a switch to quickly turn personal logics on or off. Turning off personal logistics will stop logistic robots from bringing requested items. It will also stop items from automatically being moved to the trash slots. Logistic robots will continue to empty the trash slots. Since the recipe GUI has a new style, we also updated the look of the filter, item, circuit signal, and upgrade selection GUI styles. Some of the other GUIs in the game will have some visual issues due to the mix of old and new styles. My next step will be to fix these issues as soon as the Character GUI is released. Looking back, this GUI took 13 months and 3 programmers (working alternatively) to implement. This is excluding mockups and UX design. It's a long story, but one thing that's obvious is that the GUI scope has grown far beyond what our codebase is capable of. For this reason, we won't be focusing obsessing that much on the GUI in the future. We will finalize the transition of styles, fix obvious issues and low hanging fruits, and try to get everything at a consistent level of quality for 1.0. This new Character GUI and changes will likely affect some mods, especially those relying on logistic technologies, logistic slot related APIs, old style definitions, etc. Thankfully a lot of mods will be unaffected, so we hope it won't be too much disruption. Still, we wanted to give some forewarning.
0.15 release I would be surprised if you are reading this blog and didn't know that we released the 0.15 experimental this Monday. After more than 6 months of work and effort put in, we are really happy to finally see everyone playing and enjoying it so much. We'd like to thank you all for the feedback and suggestions we've received, and for being patient with us when we couldn't keep to our plans. The whole team here is committed first and foremost to making as great a game as possible. While the delays were not insignificant, we really hope we have met your expectations and delivered on what we have promised. Initially we had a small issue with our new config system and a script we use for Steam cloud syncing, leading to the game looking for a value which was no longer there. Thankfully HanziQ solved the problem in short time, and we released 0.15.1 just 3 hours later. The rest of the week ran pretty smoothly with the typical bugfixing, while the majority of the GFX department takes a well deserved break. If you are interested in seeing an overview of all the new features, you have a choice of British or American flavour, provided by MangledPork and Xterminator respectively:
Sound design update Ian One advantage of switching to home working during the COVID-19 crisis is the ability to listen to the game using speakers rather than headphones, and this has proved useful in balancing the relative levels of the game. Val has also been getting to grips with Lua, and this has led him to working on attenuations, which have been proving problematic. For instance, we noticed that sounds such as the radar were getting cut off when you walked away from them, rather than fading out cleanly. I investigated and discovered we had a maximum environment sound limit of 15, by raising this to 50 we have eliminated many of these problems. But then the downside is that there are now more sounds playing and therefore more clutter to mix and balance. Pink squares indicate which sounds are active. Left: limit of 15 nearby sounds; Right: limit of 50 nearby sounds. Rseding has been working through the list of sound design programming tasks, for instance we finally have the sound for the artillery turret rotation integrated into the game (which was featured in FFF-252 quite a while ago). Real in-game footage of the new artillery sounds In other news, we have an updated concept for the transport belts. We listened to feedback from the community that they were still a bit too present and annoying. The idea of the new sounds is that they will drift into the distance a bit more and become unnoticed (until you try to fall asleep). More fun sounds include water splashes, electric and laser beams, more powerful weapons such as the gun turret and vehicle machine gun. And our old robot sounds have come back as additions. If all goes to plan, we will merge the sound changes into master very soon, and once we've done all our pre-release checks, release it to the 0.18 experimental. After that, I plan to spend time on UI sounds, and also balancing the overall levels to get them more in line with other games, which is trickier than normal given the lack of audio middleware. However we have also made some changes to the default sound settings that move us in the right direction.
Going through to-do list (kovarex) One of the many small tasks for 0.17, was to solve the occasional problem I had when I didn't notice that one of my trains didn't have the refuelling automated. One train out of fuel can halt all the train logistics easily, and sometimes it takes quite a while to notice it. For this reason, we added an alert for trains running out of fuel when in automatic mode.
Hello, We know you love to blow things up, and the Space Age expansion will be bringing ever more advanced and powerful ways of bearing arms against your enemies.
Hello old time Factorio players and steam newcomers as well!
New test servers We recently bought and assembled some high-end PCs, with the hope to gauge performance, speed up running tests, and potentially consolidate the number of servers we are maintaining internally. The two lucky CPUs were a i9-9980XE 18-core and a Ryzen 3900X 12-core. We are using the time to complete our test suite in 'heavy mode' as a benchmark. Heavy mode basically saves and reloads the game each tick, and compares a CRC of the map from before and after. It is super slow to run, but the heavy test is critical to help find any possible determinism issues. There is some more info on 'heavy mode' in FFF-63. As a baseline, the 'standard' CPU in the office for developers is the i9-7900x 10-core, which runs heavy tests in about 530 seconds. In real time this is 8 minutes and 50 seconds, a long time for a team member to sit around for results before they can push. We can do better! As you would expect, the new 18-core was blazing fast, with a test time of about 400 seconds, shaving off over 2 minutes. However the Ryzen was a different story, with a test time of about 600 seconds. This goes against what we predicted, where more cores and higher frequency mean lower test times. The initial results from the 12-core Ryzen were worse than from the 10-core Intel; not a good start. So I did some digging and some research, and the answer I arrived at was RAM. When we ordered the parts, not much thought was given to the selection of RAM, just some standard 16GB 2666MHz sticks to fill all the slots. Luckily, I looked on a local Czech website, and they had some stock of the brand new G.SKILL 3600MHz Trident RGB Neo, a high performance RAM stick made exactly to suit our new Ryzen CPU. After installing the new RAM, we had a test result that better matched our expectations: 450 seconds. We knew beforehand that Ryzen liked fast RAM, but we didn't realize how significant of a difference it could make. So now we have set up both these new machines to run tests automatically after each commit, and we are very happy with the result. The new i9-9980XE can compile and run heavy tests faster than our old i7-4790K can compile and run just normal tests. Having it run automatically also frees up individual developers from the responsibility of running heavy tests locally, so they can just push as normal and continue working.
Environmental particle effects Dom Since the particle optimization we did for 0.18 (FFF-322) and the introduction of new explosions (FFF-325), we were able to push our vision even more. It always bothered me that the grenade and other explosions would emit the same type of particles regardless of the context. In most cases it isn't that bad, and somewhat okay, but when you throw a grenade into water, it will still emit stone particles, which breaks the illusion. Another problem is that we have the nice decoratives on the ground, but they don't really 'interact' with anything that goes on, and can feel like fake flat stickers instead of something 'real'. You would expect that when there is a massive explosion 2ft away, the bushes might have some reaction to that. The explosion effect currently in 0.18
